home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0080 / 840.txt < prev    next >
Text File  |  1997-04-16  |  11KB  |  287 lines
  1. =========================================================================
  2.  
  3. INFO-ATARI16 Digest         Wed, 20 Dec 89       Volume 89 : Issue  840
  4.  
  5. Today's Topics:
  6.                               C question
  7.          more on strncpy (was re: laser c question) (2 msgs)
  8.             More Portfolio Ads, with a curious feature...
  9.                   USENET -> GEnie uplink now working
  10. ----------------------------------------------------------------------
  11.  
  12. Date: 18 Dec 89 12:49:34 GMT
  13. From: nis!pwcs!stag!daemon@UMN-CS.CS.UMN.EDU  (John Stanley)
  14. Subject: C question
  15. Message-ID: <1989Dec18.124934.1487@stag.UUCP>
  16.  
  17. [S61304@PRIME-A.POLY-SOUTH-WEST.AC.UK (Rat) writes...]
  18.  
  19. > Why wont Sozobon, Lattice or any other C compiler I've tried compile the
  20. > following, from K&R?
  21. >
  22. > main()
  23. >      $
  24. >      char fred[] = "Some string constant";
  25. >      <rest of routine>
  26. >
  27. >
  28. > This has been confusing me for a while, as K&R (surely correct!) would
  29. > seem to indicate that this is indeed permissible!
  30.  
  31.  (Assuming that the '$' character in the line after main() is really
  32. suppost to be a '?' character on your machine and just got garbled...??)
  33.  
  34.   Can you please tell me where in K&R this example is used?
  35.  
  36.   The problem is because you can't assign a string to an unknown size
  37. array at runtime (at least not that way)...  The array you give there
  38. needs to be defined with:
  39.  
  40.         static char fred[] = "Some string constant";
  41.  
  42.   Defining the array as static tells the compiler you want the array to
  43. be created-and-initialized, as-shown, at compile-time.
  44.  
  45.   To assign the array at runtime, you've got a number of options, but the
  46. easiest way is:
  47.  
  48.         main()
  49.                 ?
  50.                 char fred[22];
  51.  
  52.                 strcpy(fred, "Some string constant");
  53.                 <rest of routine>
  54.                 ?
  55.  
  56. ---
  57. John Stanley <dynasoft!john@stag.UUCP>
  58. Software Consultant / Dynasoft Systems
  59.  
  60. ------------------------------
  61.  
  62. Date: 18 Dec 89 12:49:32 GMT
  63. From: nis!pwcs!stag!daemon@UMN-CS.CS.UMN.EDU  (John Stanley)
  64. Subject: more on strncpy (was re: laser c question)
  65. Message-ID: <1989Dec18.124932.1486@stag.UUCP>
  66.  
  67. [kirkenda@.cs.pdx.edu (Steve Kirkendall) writes...]
  68. >
  69. > In article <1870@calvin.cs.mcgill.ca> depeche@calvin.cs.mcgill.ca (Sam Alan
  70.  EZUST) writes:
  71. >>someone already sent me dlibs memcpy which I believe is what is used
  72. >>in Sozobon.... However, I don't have an assembler and am not too
  73. >>much of an expert in it anyway, so I couldn't get it installed on
  74. >>my system without help.
  75. >
  76. > Okay, here's one in C:
  77. >
  78. >       memcpy(dest, src, count)
  79. >               register char   *dest;  /* destination address */
  80. >               register char   *src;   /* source address */
  81. >               register int    count;  /* number of bytes to copy */
  82. >       ?
  83. >               while (--count >= 0)
  84. >                       *dest++ = *src++;
  85. >       ?
  86. >
  87. > This can copy up to 32767 bytes at a time.  It isn't very fast, though.
  88.  
  89.   Actualy, it can copy up to 65535 bytes if you change:
  90.  
  91.                 while (--count >= 0)
  92.         into
  93.                 while (count-- != 0)
  94.  
  95.   While the parameter passed to memcpy is usualy documented to be just an
  96. int, it's not uncommon for versions of memcpy to treat the count variable
  97. as an unsigned integer instead which doubles the amount to memory that
  98. can be moved with a single call...
  99.  
  100.   (Before you use this, be sure your code isn't going to have to deal
  101. with copying negative numbers of bytes... only 1/2 :~)
  102.  
  103. ---
  104. John Stanley <dynasoft!john@stag.UUCP>
  105. Software Consultant / Dynasoft Systems
  106.  
  107. ------------------------------
  108.  
  109. Date: 18 Dec 89 12:49:47 GMT
  110. From: nis!pwcs!stag!daemon@UMN-CS.CS.UMN.EDU  (John Stanley)
  111. Subject: more on strncpy (was re: laser c question)
  112. Message-ID: <1989Dec18.124947.1535@stag.UUCP>
  113.  
  114. [depeche@quiche.cs.mcgill.ca (Sam Alan EZUST) writes...]
  115. [.. responding to email I sent to him ..]
  116.  
  117. > :   Alternately, does Lazer C allow copying structures using a simple
  118. > : assignment?  <struct2> = <struct1>;  If so, what I've ocassionaly used in
  119. > : situations like yours is to define a struct containing the array and
  120. > : moved copys of the array arround by just using assignments...
  121. >
  122. > that's a good idea. I should try it. I didn't think it was possible though,
  123. > as struct names are just pointers to memory locations of data, just
  124. > like arrays,
  125.  
  126.   Nope.  A struct name is the name of a structure.  It is -not- a pointer
  127. even though it has an address that you can obtain by using: &structname
  128. (Note that the address you obtain (unless you cast it or store it into a
  129. pointer of some other type) still "knows" that it's pointing to a struct
  130. so if you use *(&structname) it references the original structure, not
  131. just the 1st byte in the structure.
  132.  
  133.   *(unsigned char *)(&structname) would give you the structures 1st byte...
  134.  
  135. > and you can address the 5th byte of a structure with
  136. > *(structname+5) just like arrays.
  137.  
  138.   Nope....  *(structname+5) is an illegal construct.  You can't increment
  139. a structure itself and contrary to your assumption, a structname is -not-
  140. the same as a pointer to a structure.
  141.  
  142.   On the other hand, ((&structname)+5) (which is different) would point
  143. to a location 5 STRUCTURES higher in memory than &structname.  In C, any
  144. addition to a pointer is taken as increasing the pointer by (the value
  145. added multiplied by the size of the object being pointed at (in this case
  146. a structure)).  This sometimes causes confuses because many people
  147. normaly only deal with arrarys of characters (so the sizeof object == 1).
  148.  
  149.   Example:
  150.  
  151.         struct foo
  152.                 ?
  153.                 int foo_1[32][100];
  154.                 ?;
  155.  
  156.         foocpy()
  157.                 ?
  158.                 struct foo src, dst;
  159.  
  160.                 /* if your compiler allows structure assignment, */
  161.                 /* the next line should copy an array 32 x 100   */
  162.                 /* integers long with a single assignment...     */
  163.  
  164.                 dst = src;
  165.  
  166.                 /* individual elements would be referenced as... */
  167.  
  168.                 src.foo_1[23][7] = 2619;
  169.                 ?
  170.  
  171. > you are exactly right. However, I got it working now via the brute-force
  172. > loop-of-assign statements. If I can get dlibs installed properly on
  173. > Laser C (and I am having trouble, as you will soon see in one of
  174. > my messages posted on c-s-a-st which I posted today), I will then
  175. > translate them all into memcpy's.
  176.  
  177.   Good luck.  You may still want to consider using struct assignments
  178. since I've been told Lazer-C does support them...
  179.  
  180. > :   .. although, it would be a real-good-idea if you posted a note on the
  181. > : net mentioning that strncpy doesn't move <n> bytes so other beginning
  182. > : programmers who see your message won't think that it's a correct
  183. > : substitution....
  184. >
  185. > ok.. I shall. Thanks for your help/reply!!
  186.  
  187.   You're welcome...
  188.  
  189. > --
  190. > S. Alan Ezust                                   depeche@calvin.cs.mcgill.ca
  191. > McGill University Department of Computer Science - Montreal, Quebec, Canada
  192.  
  193. ---
  194. John Stanley <dynasoft!john@stag.UUCP>
  195. Software Consultant / Dynasoft Systems
  196.  
  197. ------------------------------
  198.  
  199. Date: 20 Dec 89 02:19:47 GMT
  200. From: nis!pwcs!stag!daemon@UMN-CS.CS.UMN.EDU  (John Stanley)
  201. Subject: More Portfolio Ads, with a curious feature...
  202. Message-ID: <1989Dec20.021947.6026@stag.UUCP>
  203.  
  204. [gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) writes...]
  205. [.. talking about an ad for the Portfolio ..]
  206.  
  207. > However, I noticed something quite strange -- the display is simulated
  208. > because you can't take a photo of a LCD display...
  209.  
  210.   Why tell people something like that?  You -can- take a picture of an
  211. LCD display.  Why would you think otherwise?  (Yes, you have to get the
  212. lighting right, but that's true of many photo subjects.  It's certanly
  213. not "impossible"...)
  214.  
  215. > but the font used is proportionately spaced!
  216.  
  217.   This, on the other hand is a pretty good reason for thinking it's a
  218. "simulated" screen...  :~)
  219.  
  220. ---
  221. John Stanley <dynasoft!john@stag.UUCP>
  222. Software Consultant / Dynasoft Systems
  223.  
  224. ------------------------------
  225.  
  226. Date: 19 Dec 89 17:17:34 GMT
  227. From: thelake!steve@UMN-CS.CS.UMN.EDU  (Steve Yelvington)
  228. Subject: USENET -> GEnie uplink now working
  229. Message-ID: <1119891117345517@thelake.UUCP>
  230.  
  231. In article <15097@well.UUCP>,
  232.      dsmall@well.UUCP (David Small) writes ...
  233.  
  234. (lots of stuff about Usenet <--> GEnie link.)
  235.  
  236. >       Systems like Compuserve and BIX could also fairly easily be done,
  237. >now that the methodology is hacked through; also, other areas on GEnie are
  238. >expressing great interest in having a USENET uplink. Basically, folks,
  239. >USENET is perceived as the place where the people who know what they're
  240. >doing post notes.
  241.  
  242. I don't think any Usenet news is available on Compu$erve, but it already
  243. has an e-mail link to the Internet via Ohio State University. In theory,
  244. e-mail to 71234,567 would be addressed to
  245.  
  246.   71234.567@compuserve.com
  247.  
  248.     or (from BITnet or other balky mail sites)
  249.  
  250.   71234.567%compuserve.com@saqqara.cis.ohio-state.edu
  251.  
  252. Note that the comma in the CIS userid has been changed to a dot in order
  253. to meet RFC822 standards.
  254.  
  255. From Compu$erve to the Internet, it's
  256.  
  257.     >internet:user@host.domain
  258.  
  259. John Chew <poslfit@gpu.UTCS.UToronto.CA> maintains a list of internetwork
  260. E-mail methods and posts it monthly to comp.mail.misc and
  261. news.newusers.questions.
  262.  
  263. Last I heard, Delphi was carrying the Usenet rec.humor.funny newsgroup
  264. (with Brad Templeton's blessing). I don't think it has hooked e-mail into
  265. the free world, even though it would be quite easy -- plenty of other VMS
  266. sites have done so. It does exchange e-mail with other commercial
  267. services.
  268.  
  269. BIX is not, to my knowledge, e-mail accessible from the Internet and UUCP.
  270.  
  271. However, Jefferson Software in Phoenix (the Modula-2 folks where kbad used
  272. to work) has developed a program for the ST that allows the transfer of
  273. BIX public conferences into RFC1036 (Usenet news) format, stored in a
  274. standard Usenet batchfile, and vice versa.
  275.  
  276. It currently is being used to internetwork BIX with several Citadel/STadel
  277. BBS network discussion topics (rooms). I think the software is capable of
  278. dumping Usenet news into BIX, and vice versa.
  279.  
  280. --
  281.    Steve Yelvington at the (frozen enough to skate!) lake in Minnesota
  282.    UUCP: ... pwcs.StPaul.GOV!stag!thelake!steve
  283.  
  284. ------------------------------
  285.  
  286. End of INFO-ATARI16 Digest V89 Issue #840
  287. *****************************************